Repository navigation
fix(recompiler): read P20 of a flat input as the provoking vertex - #8538
Conversation
|
Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
|
Verified the title fix on Linux / NVIDIA at SuperTuxKart PPSA69421 00.001.000, unchanged
Each counted process completed the same approximately 67-second capture window and exited normally after SIGINT. The restored-head run was made after the negative-control process had fully exited. Linux prerequisite: every title arm includes only #7897's Focused control: temporarily adding a dispatch directly to the existing This supports the flat-input correction, rather than our earlier kill/target-preservation hypotheses. No Khronos validation layer is installed here; no validation-layer or console-semantics claim. No retail titles tested. The temporary edits are removed. |
|
Windows 11 Pro, Intel Core i9-14900K, 128 GB, NVIDIA GeForce RTX 5080 (driver 32.0.16.1742), WinLibs GCC 15.2.0, Release, SuperTuxKart (PPSA69421 00.001.000, catalog release)
Tests, with
Verdict: works on Windows with an RTX 5080. The SuperTuxKart black rectangle is gone, the new test fails without the change, and no related test or validation result changed. |
MarcZX10
left a comment
MarcZX10
left a comment
There was a problem hiding this comment.
The P20 handling is consistent with the existing P10 model: flat inputs read only through P20 remain flat, the collector marks P20 use separately, and pipeline validation rejects the unmeasured provoking-vertex combination. The cache artifact stores the new flag, and its generated source-version hash covers the recompiler/cache sources. The added focused graphics test checks first/last provoking behavior, and the independent Linux/NVIDIA and Windows/NVIDIA title reports on this head confirm the SuperTuxKart symptom is fixed with the shader unchanged. Hosted runtime/build jobs were skipped, so I am relying on those reported exact-head runs plus static review.
97f6020 to
3d4a230
Compare
|
Rebased onto Radeon 860M, Windows 11, AMD 32.0.13058.8001,
|
3d4a230 to
93c1b09
Compare
github-actions
Bot
added
needs rebase
A FLAT_SHADE input without pass-through that a pixel shader reads through v_interp_mov_f32 P20 and not P10 stayed an explicit per-vertex input and read vertex 2 minus vertex 0. For a flat value that is the same on every vertex the difference is 0, and with the first provoking vertex nothing refused it. ps5-opengl lowers every flat input to a load of one vertex: vertex 1 (P10) by default, which boykopovar#4030 reads as the provoking vertex, and vertex 2 (P20) for triangles when GL's flatshade_first is set. SuperTuxKart's deferred point lights are drawn that way, so all twelve flat inputs of pointlight.frag read 0, the attenuation 0 * -inf was NaN, nothing was discarded, and the starting-line referee's light quad blacked out the scene behind it (boykopovar#8364). A P20-only read now returns the provoking vertex's value, as P10 and P0 do. The lane was not measured on the console either, so FragmentParameter records it and a pipeline using the last provoking vertex throws. An input read through both P10 and P20 keeps its per-vertex differences. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
93c1b09 to
1bf43f9
Compare
|
Rebased onto current |
What
A FLAT_SHADE input without pass-through that a pixel shader reads through
v_interp_mov_f32P20 and not P10 now returns the provoking vertex's value, like P0, and like P10 since #4030. Before, P20 kept the input explicitly per vertex and read vertex 2 minus vertex 0. For a flat value, that difference is 0 on every vertex, and with the first provoking vertex nothing refused the draw.Why. ps5-opengl lowers every flat input to a load of a single vertex in
lower_flat_input_vertex(toolchain/opengnm-psbc-ps5.patch, mirror):ps5_last_provoking_vertex(primitive_type): vertex 2 for triangles, 1 for lines, 0 for points.That driver passes the GL 4.6 CTS on a PS5, the argument #4030 rests on (#1413).
Seen in SuperTuxKart. SuperTuxKart (PPSA69421) draws its deferred point lights this way. All 12 flat inputs of
pointlight.frag(center,energy,col,radius,direction_scale_offset) are read through P20 under the first provoking vertex, so onmainthey are all 0.att = energy * 20. / (1. + d * d) * (radius - d) / radiusis then0 * -inf, which is NaN;if (att <= 0.) discard;is false for NaN, so nothing is discarded. The light's whole screen-space quad writes NaN into the light accumulation targets, and the starting-line referee and everything behind it render black. Details in #8364:pointlight.fragalso fixes it;Changes.
ShaderInfoCollectorkeeps a flat input per vertex only when it is read through both P10 and P20. The existing "differences to vertex 0" cases inagc_driver_graphicsandagc_shader_memoryread both, and are unchanged.FragmentParametergainsflatP20, set the same way asflatP10and stored in the shader disk cache.ValidateProvokingVertexthrowsv_interp_mov p20 of a flat input with the last provoking vertex is not measuredwith the last provoking vertex. Neither combination was measured on a console, so the pairing that ps5-opengl doesn't produce throws, as for P10 under the first.Tested
Windows 11 Home 26300, AMD Radeon 860M (
1002:1114, driver 32.0.13058.8001), WinLibs GCC 15.2.0, Release,ANYPS5_REQUIRE_VULKAN=1, based onmain75787d2.agc_driver_graphicsgets a P20 case mirroring fix(recompiler): read P10 of a flat input as the provoking vertex #4030's P10 one. The input compiles to a flat input;flatP20is set andflatP10is not; first mode passes; last mode throws. Negative control: withmain'sShaderInfoCollector.cpp,SpirvInputOutput.cppandPipeline.cpp, it fails withflat v_interp_mov P20 did not compile to a flat input.ctest -R "agc|shader|spirv|recomp" -j4 --timeout 120: 840 of 841 pass, 3 skipped for device features. The one left isagc_driver_image_array_window_past_layer_limit, Not Run because it does not compile with MinGW (requested alignment '65536' exceeds object file maximum 8192, also onmain).The 35 tests matching
provok|flat|interp|barycentric|rect_list|strip: all 32 that build here pass.SuperTuxKart (PPSA69421 00.001.000), tutorial race started through
APS5_PAD_INPUT_FILE, unmodified game files. The referee during "Ready! / Set! / Go!":main: black rectangle and black bird on every run (more than 10 today, on severalmaincommits);Other ps5-opengl titles, 60 s each, no input,
mainand this PR:The only refusal logged is the existing P10 one (
shader library prebuild skipped: ... p10 of a flat input with the first provoking vertex is not measured), on both trees.Not run: the Khronos validation layer (not installed on this machine), and GPUs other than the 860M.
Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file.mdfiles or images added to the repository (attach them to this PR)1002:1114), AMD driver 32.0.13058.8001, Windows 11 26300Overlap from
tools/pr_overlap.py: #6741 and #7426 change the last-provoking-vertex checks in the sameValidateProvokingVertex. #6741, #7426, #7883, #7893 and #8083 edit the same debt line. None of them reads P20 of a flat input.